1
Ex No: 1 PROBLEM STATEMENT
AIM: To prepare a PROBLEM STATEMENT for any project.
REQUIREMENTS:
Hardware Interfaces
Pentium(R) 4 CPU 2.26 GHz, 128 MBRAM
Screen resolution of at least 800 x 600 required for proper and complete
viewing of screens. Higher resolution would not be a problem.
CD ROM Driver
Software Interfaces
Any Windows-based operating system
WordPad or Microsoft Word
THEORY:
The problem statement is the initial starting point for a project. It is basically a
one-to-three-page statement that everyone on the project agrees with that describes
what will be done at a high level. The problem statement is intended for a broad
audience and should be written in non- technical terms. It helps the non-technical and
technical personnel communicate by providing a description of a problem. It doesn't
describe the solution to the problem.
The input to requirement engineering is the problem statement prepared by
customer. It may give an overview of the existing system along with broad expectations
from the new system.
The first phase of requirements engineering begins with requirements elicitation i.e.
gathering of information about requirements. Here, requirements are identified with the
help of customer and existing system processes. So, from here begins the preparation of
problem statement.
So, basically a problem statement describes what needs to be done without
describing how.
Conclusion: The problem statement was written successfully by following the steps
described above.
2
3
Ex No: 2 SYSTEM REQUIREMENT SPECIFICATION
AIM: Understanding an SRS.
REQUIREMENTS:
1. Hardware Requirements:
PC with 300 megahertz or higher processor clock speed recommended;
233 MHz minimum required.
128 megabytes (MB) of RAM or higher recommended (64 MB minimum
supported)
1.5 gigabytes (GB) of available hard disk space
CD ROM or DVD Drive
Keyboard and Mouse (compatible
pointing device).
2. Software Requirements:
Rational Rose, Windows XP,
THEORY:
An SRS is basically an organization's understanding (in writing) of a customer
or potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance
policy that assures that both the client and the organization understand the other's
requirements from that perspective at a given point in time.
The SRS document itself states in precise and explicit language those functions
and capabilities a software system (i.e., a software application, an e-commerce web
site, and so on) must provide, as well as states any required constraints by which the
system must abide. The SRS also functions as a blueprint for completing a project with
as little cost growth as possible. The SRS is often referred to as the "parent" document
because all subsequent project management documents, such as design specifications,
statements of work, software architecture specifications, testing and validation plans,
and documentation plans, are related toit.
It's important to note that an SRS contains functional and nonfunctional
requirements only; it doesn't offer design suggestions, possible solutions to technology
or business issues, or any other information other than what the development team
understands the customer's system requirements to be.
A well-designed, well-written SRS accomplishes four major goals:
It provides feedback to the customer. An SRS is the customer's assurance that
the development organization understands the issues or problems to be solved
and the software behaviour necessary to address those problems. Therefore, the
SRS should be written in natural language (versus a formal language, explained
later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and soon.
4
It decomposes the problem into component parts. The simple act of writing
down software requirements in a well-designed format organizes information,
places borders around the problem, solidifies ideas, and helps break down the
problem into its component parts in an orderly fashion.
It serves as an input to the design specification. As mentioned previously, the
SRS serves as the parent document to subsequent documents, such as the
software design specification and statement of work. Therefore, the SRS must
contain sufficient detail in the functional system requirements so that a design
solution can be devised.
It serves as a product validation check. The SRS also serves as the parent
document for testing and validation strategies that will be applied to the
requirements for verification.
SRSs are typically developed during the first stages of "Requirements
Development," which is the initial product development phase in which information is
gathered about what requirements are needed--and not. This information-gathering
stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's
current business environment. The actual specification, then, is written after the
requirements have been gathered and analysed.
SRS should address the following:
The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed todo?
b) External interfaces. How does the software interact with people, the system‘s
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
d) Attributes. What are the portability, correctness,
maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation. Are there any required
standards in effect, implementation language, policies for database integrity,
resource limits, operating environment(s)etc.?
5
Characteristics of a good SRS
An SRS should be
Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable
Correct - This is like motherhood and apple pie. Of course you want the specification
to be correct. No one writes a specification that they know is incorrect. We like to say -
"Correct and Ever Correcting." The discipline is keeping the specification up to date
when you find things that are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated
therein has only one interpretation. Again, easier said than done. Spending time on this
area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix
them.
Complete - A simple judge of this is that is should be all that is needed by the software
designers to create the software.
Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop"
in another.
Ranked for Importance - Very often a new system has requirements that are really
marketing wish lists. Some may not be achievable. It is useful provide this information
in the SRS.
Verifiable - Don't put in requirements like - "It should provide the user a fast response.
"Another of my favourites are - "The system should never crash." Instead, provide a
quantitative requirement like: "Every key stroke should provide a user response within
100milliseconds."
Modifiable - Having the same requirement in more than one place may not be wrong -
but tends to make the document not maintainable.
Traceable - Often, this is not important in a non-politicized environment. However, in
most organizations, it is sometimes useful to connect the requirements in the SRS to a
higher- level document. Why do we need this requirement?
6
A sample of basic SRS Outline
1. Introduction
Purpose
Document conventions Intended
audience
Additional information
Contact information/SRS team members
References
2. Overall Description
Product perspective
Product functions
User classes and characteristics
Operating environment
User environment
Design/implementation constraints
Assumptions and dependencies
3. External Interface Requirements
User interfaces
Hardware interfaces
Software interfaces
Communication protocols and interfaces
4. System Features
System feature A
Description and priority
Action/result
Functional requirements
System feature B
5. Other Non-functional Requirements
Performance requirements
Safety requirements
Security requirements
Software quality attributes
Project documentation
User documentation
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined
Conclusion: The SRS was made successfully by following the steps described above.
7
Ex No: 3 LIBRARY MANAGEMENT SYSTEM
PROBLEM DEFINITION
The library management system is software, which automates the job of a librarian.
The user can inquire about the availability of a book in which he can search by entering the
authors name or by entering the title of the book.
The user can borrow a book. He must provide the username and the card number, which is unique
and confidential to each user. By confirming the authenticity of a user, the library management
system provides information about the number of books already borrowed by the user and by
referring to the database whether the user can borrow books or not. The library management
system allows the user to enter the title and the author of the book and hence issues the book if it
is available.
By entering the user details and the book details the user can return the borrowed book.
SYSTEM REQUIREMENTSPECIFICATION
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in developing a Library
management system. The intended audience is any person, who wants to inquire, borrow and
return the books.
Scope
The product is titled Library Management System.
The product will perform the following tasks Enquire about the availability of books.
Borrow books if available.
Return the borrowed books.
Definitions, Acronyms and Abbreviations DBMS Database Management System.
References
IEEE standard 830-1998 recommended practice for Software Requirements Specifications-
Description.
Overview
The SRS contains an analysis of the requirements necessary to help easy design.
8
The overall description provides interface requirements for the Library Management
System, product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and other constraints.
Succeeding pages illustrate the characteristics of typical naïve users accessing the system
along with legal and functional constraints enforced that affect Library Management System
in any fashion.
THE OVERALLDESCRIPTION
Product perspective
Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration that is on-line. This
makes it necessary to have a fast database system running on high rpm hard disk permitting
complete data redundancy and back-up systems to support the primary goal of reliability.
The system must interface with the standard output devise, keyboard and mouse to
interact with this software. Software interfaces
Back End: MS-Access 2007
Front End: Microsoft Visual Basic 6.0
Memory Constraints
No specific constraints on memory.
Operations
The software allows three modes of operations 2.2.1.4.1.1 Enquire about the availability
and status of books. By extracting the username and password the software allows the
user to borrow a maximum of three books. By extracting the username and password the
software allows the user to return the borrowed books. Product Functions
Enquire about the availability and status of books.
Search the availability of book by entering the title of the book.
Search the availability of book by entering the author of the book.
The software validates the authentic user by extracting their user name and
password.
After the validation of the user software allows the user to borrow a maximum of three
books based on the number of books which where already borrowed.
After the validation of the user software allows the user to return the books, which where
borrowed.
9
User characteristics
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus, the end user is at a high level of abstraction that
allows easier, faster operation and reduces the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the native users.
The product does not expect the user to possess any technical background. Any person who
knows to use the mouse and the keyboard can successfully use this product.
Constraints
The user has a unique username and password, there are no options to retrieve a password or
username in case it is forgotten or lost hence the user is requited to remember or store the
username and password.
SPECIFICREQUIREMENTS
Logical Database Requirements
The system should contain databases that include all necessary information for the product
to function according to the requirements. These include relations such as user details and
book details.
The user details refer to the information such as name, card number, no. of books borrowed,
the title and the name of the author of the books that were borrowed.
The book details refer to the information such as the title of the book, author availability status
and the number of copies that is available.
FRONT ENDDESCRIPTION
The library management system is automated library system where the user can
search for the book by either entering the details of the book or the authors name. By
entering the username and the password the software, by checking the number of books that
are already borrowed enables us to borrow a maximum of three books. And by entering the
username and password (card number), which is unique, the user can return the books.
BACK ENDDESCRIPTION
The library management system consists of two tables. One contains the student
details such as the name, card number that is the password, title and the author of the three
books, which could be borrowed. The book details consist of the title of the book, number of
copies, author and the availability status.
10
DATASTRUCTURES
BOOK DETAILS
FIELD NAME
TYPE
CONSTRAINTS
REGISTER_NO
NUMBER
NOT NULL
BOOK_ID
NUMBER
NOT NULL
ISSUE_DATE
DATE/TIME
RETURN_DATE
DATE/TIME
BOOK_NAME
TEXT
STUDENT DETAILS
FIELD NAME
TYPE
REGISTER_NO
NUMBER
FNAME
TEXT
LNAME
TEXT
GENDER
TEXT
DEPT
TEXT
EMAIL
TEXT
PASSWORD
TEXT
NO_OF_BOOKS
NUMBER
11
DATA FLOWDIAGRAM
12
TESTING:
FORM NAME
INPUT
EXPECTED
OUTPUT
ACTUAL
OUTPUT
STATUS
MAIN MENU
FORM
Menu Option
Show
required
Form
Required
Form was
displayed
Pass
MEMBERSHIP
FORM
Member
details are
entered
Create new
member account
New Account
was created
Pass
LOGIN FORM
Member ID
and password
If password is
correct, login.
Member
authenticated
for future
operations.
Pass
ISSUE FORM
Book ID
If books issued is
less than three,
issue the book.
Book issued
Pass
RETURN/REISSUE
FORM
Book ID
Book returned/
reissued
Book
returned/
Reissued
Pass
BOOK ENQUIRY
Book Name
Book details are
displayed
Book details
are displayed
Pass
13
SAMPLE FORMS
MAIN MENU FORM
MEMBERSHIP FORM
14
LOGIN FORM
ISSUE FORM
15
RETURN/REISSUE FORM
BOOK ENQUIRY FORM
RESULT:
Thus, the online Library System was implemented using the specified front end and back
end tools.
16
17
Ex No: 4 AUTOMATED BANKING SYSTEM
PROBLEM DEFINITION
To develop an automated banking system, which is required to perform the following functions:
The customer logs into the system using card number and pin number. The system checks for
validation.
The system queries the customer for the type of account either fixed deposit or credit
account. After getting the type of account the system shows the balance left.
The system queries the customer for the transaction type either withdrawal or deposit and the
required amount. The user enters the amount and the
transaction if carries out
SRS DOCUMENT FOR AUTOMATED BANKINGSYSTEM
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in developing an
Automated Banking System (ABS). The intended audience is any person who wants to
create account.
To withdraw or deposit either in fixed deposit or credit account.
Scope
The product is titled Automated Banking System (ABS).
The product will perform the following tasks
Allow a new user to create an account, either fixed or credit account by entering the details
and by depositing an initial amount.
Allow the existing user to enter his account details like card number, pin number and account
type to view his balance.
Allow the existing user to deposit an amount by entering the amount to be deposited after
the balance had been viewed. Allow the existing user to withdraw an amount by entering the
amount to be withdrawn after the balance had been viewed. The primary benefits expected
of the system are: user friendly, continuous connectivity without failure, fault tolerant and
involves lesser manpower.
Definitions, Acronyms and Abbreviations ABS: Automated
Banking System.
18
References
IEEE standard830-1998recommended practicefor Software
Requirements Specifications-Description.
IEEE SoftwareRequirements Specifications
Templatehttp://www.cas.master.ca/~carette/SE3M04/2
003/files/ srs_template.doc
Overview
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Banking system, product
perspective, hardware interfaces, software interfaces, communication interface, memory
constraints, product functions, user characteristics and other constraints.
Succeeding pages illustrate the characteristics of typical naïve users accessing the system
along with legal and functional constraints enforced that affect banking system in any
fashion.
THE OVERALLDESCRIPTION
Product perspective Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration that is on-line. This
makes it necessary to have a fast database system (such as any RDBMS) running on high
rpm hard-disk permitting complete data redundancy and backup systems to support the
primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to interact with
this software.
Software interfaces
Back End: MS Access2007
Front End: Microsoft Visual Basic 6.0
Operations
The user can create a new account.
The existing user can access his account and view his balance by entering his details.
The user can deposit and withdraw money from his account.
19
Product Functions Creating a New Account
The user should provide his personal details to facilitate the bank clerk to create a new
account. The user should provide:
Customer Name.
Customeraddress.
Required account type.
Pin Number.
Initial deposit.
Operating with created account
The user should be able to operate with his new account after:
Entering card number.
Entering pin number.
Entering the account type, transaction type and amount involved in the transaction.
User characteristics
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of abstraction that
allows easier, faster operation and reduces the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the naïve users.
The product does not expect the user to possess any technical background. Any person who
knows to use the mouse and the keyboard can successfully use this product.
Constraints:
At the time of creating the new account, each user gives a pin number and is provided with a
unique card number that must be used for further transactions. Hence the user is required to
remember or store these numbers carefully.
At the time of creating the new account, the initial deposit should not be less than the specified
amount.
SPECIFIC REQUIREMENTS
Logical Database Requirements
The system should contain databases that include all the necessary information for the
product to function according to the requirements. These include relations such as Customer
Details and Account Details.
Customer details refer to the customers name and address. Account details of the customer
include the card number, account type, transaction type and the pin number given by the
user to be used at the time of the transaction at the bank.
20
FRONT ENDDESCRIPTION
The front end for the Automated Banking System (ABS) is designed using Microsoft
Visual Basic 6.0. The front end contains a user-friendly interface. The first form contains a
welcome screen that provides an option for the user to either crate a new account or to
operate through an existing account. The create account” module contains a provision to
create a new account after collecting the customer name, address and other details. The card
number and pin number of the user is obtained every time there is a transaction. The user is
requested to select the required type of transaction and the amount involved in the
transaction.
BACK ENDDESCRIPTION
The Automated Banking System (ABS) database contains only one table. It
correlates a unique card number, customer name, account type, pin number and the balance.
DATASTRUCTURES
ACCOUNT DETAILS
FIELD NAME
TYPE
CONSTRAINTS
NAME
TEXT
ACC_NO
AUTONUMBER
NOT NULL
AGE
NUMBER
GENDER
TEXT
EMAIL
TEXT
PHONE_NO
NUMBER
PASSWORD
TEXT
BALANCE
NUMBER
21
DATA FLOWDIAGRAM:
TESTING
FORM NAME
INPUT
EXPECTED
OUTPUT
ACTUAL OUTPUT
STATUS
MAIN MENU
FORM
Menu Option
Required Form must
be
Required form was
displayed
Pass
displayed
ACCOUNT
User Details are
entered
Create a new account
New account was
created
Pass
CREATION
FORM
LOGIN FORM
Account ID and
password are entered
If passwords match,
login
User permitted to
perform further
operations
Pass
WELCOME FORM
User can select
deposit, withdraw or
view balance
Show Deposit form
or Withdraw form or
view balance
Deposit form or
withdraw form or
balance is displayed
Pass
DEPOSIT
Amount to be
Deposit amount
Amount was
Pass
FORM
deposited is entered
deposited
WITH DRAW
FORM
Amount to be
withdrawn is Entered
Withdraw amount
Amount was
withdrawn
Pass
Queries
for
details
Queries
for
details
Commits
transaction
Enters
a/c
number
+
pin
number
Update
Checks
for
availab
ility
D
i
s
p
l
a
y
s
r
e
p
o
r
t
on
a/cdetails
Generates
error
report
about
new
transaction
User
Administrator
22
SAMPLEFORMS
MAINMENUFORM
ACCOUNT CREATION FORM
23
LOGIN FORM
WELCOME FORM
24
DEPOSIT FORM
WITHDRAW FORM
RESULT
Thus, the requirements involved in developing an Automated Banking System was
completed successfully.
25
Ex No: 5 AIRLINE RESERVATION SYSTEM
PROBLEM DEFINITION
Ticket reservation system for airlines has to be developed.
The system developed should contain the following features
The system should contain the following features
Search for information about the flight by means of flight number and destination
While displaying information about the flight it has to provide availability of seats.
While reserving tickets the system obtains following information from the user
o Passenger Name, Sex, Age, Address.
o Credit Card Number, Bank Name.
o number, Flight name, Date of Journey and number of tickets to be booked.
Based on the availability of tickets, the ticket has to be issued. The ticket issued should
contain the following information ticket number, flight no, flight name, date of journey,
number of passengers, sex, age and departure time.
Cancellation of booked tickets should be available.
SRS DOCUMENT FOR AIRLINE RESERVATIONSYSTEM
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in developing a Airline
Reservation system (ARS).
The intended audience is any person who wants to reserve or cancel tickets or to check the
availability of Airline tickets
Scope
The product is titled Airline Reservation system (ARS).
The product will perform the following tasks
The software that is being developed can be used to check the availability of the flight tickets for
the specified flight, destination and date of journey
If the tickets are available to the users needs and specification, then the software provide a
facility to book the tickets.
If the passengers want to cancel the tickets, he can use the cancellation module of the Airline
Reservation System.
Definitions Acronyms and Abbreviations ARS: Airline Reservation System.
26
References
IEEE standard 830-1998 recommended practice for Software
Requirements Specifications-Description.
Overview
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Airline Reservation system,
product perspective, hardware interfaces software interfaces,, communication interface,
memory constraints, product functions, user characteristics and other constraints.
Succeeding pages illustrate the characteristics of typical naïve users accessing the system
along with legal and functional constraints enforced that affect Airline Reservation system
in any fashion.
THE OVERALLDESCRIPTION
Product perspective
Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration with a fast database
system running on high rpm hard-disk permitting complete data redundancy and back-up
systems to support the primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to interact with
this software.
Software interfaces
Back End: MS Access2007
Front End: Microsoft Visual Basic 6.0
Operations
The user mode enables the end-users to do the end user operations like checking the availability,
reserving and cancelling of flight tickets.
Product Functions
Viewing Flight Details
27
The user must have the access up-to-date information about the flights including
Flight number
Flight Name
Flight route (Start and Destinationstations)
Flight timings
Seat availability.
Reserving Tickets
The user must be able to reserve tickets after selecting
Flight number
Flight Route Cancelling Tickets
The user must be able to cancel tickets that he has earlier reserved by quoting the ticket number,
credit card number and bank name.
User characteristics
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus, the end user is at a high level of abstraction that
allows easier, faster operation and reduces the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the naïve users.
The product does not expect the user to possess any technical background. Any person who
knows to use the mouse and the keyboard can successfully use this product.
Constraints
At the time of reservation, each user is provided a unique ticket number that must be used
for further operation like cancellation. Hence the user is required to remember or store this
number carefully.
SPECIFICREQUIREMENTS
Logical Database Requirements
The system should contain databases that include all necessary information for the product
to function according to the requirements. These include relations such as flight details,
reservation details, and cancellation details.
The user details refer to the information such as flight number and name, start and destination
stations, seat availability.
28
Reservation details refer to personal information that is obtained from the user
At the time of reservation, the passenger is provided a unique ticket no that could be used at the
time of cancellation.
While displaying any information about the flight it has to provide the following
information Flight no and name
Availability of seats for the particular flight
The flight timing
The passenger personal details should be obtained for reserving the tickets.
FRONT END DESCRIPTION
The front-end for the Airline Reservation system (ARS) is designed using Microsoft
Visual Basic 6.0. The front-end contains a user- friendly interface. The first form contains a
welcome screen that provides an option for the user to select one of the following
Enquiry
Reservation
Booking details
Cancellation
In the Enquiry form the user can get details of the flight by means of either flight
name destination or date 0of journey. In the reservation form, there can book details by
entering the personal details. The ticket is displayed with details about the flight name and
number, number of passengers, ticket number, sex and age. The cancellation form helps the
user to cancel a ticket, which he had booked earlier.
BACK ENDDESCRIPTION
The Airline Reservation system consists of two tables. One contains the flight details
such as the flight name, flight number, destination, date of journey and seats available in
each class that is referred to during enquiry. The other table has the passenger details such as
name, age, sex, credit card number, and bank name. This table is referred to at the time of
reservation or cancellation.
29
DATASTRUCTURES
FLIGHTDETAILS
FIELD NAME
TYPE
CONSTRAINTS
ROUTE_NAME
TEXT
NOT NULL
FLIGHT_NO
NUMBER
NOT NULL
SEATS_AVAIL
NUMBER
JOURNEY_DATE
DATE/TIME
DEP_TIME
DATE/TIME
ARR_TIME
DATE/TIME
COST
NUMBER
PASSENGER DETAILS
FIELD NAME
TYPE
CONSTRAINTS
TICKET_NO
AUTONUMBER
NOT NULL
NAME
TEXT
NOT NULL
GENDER
TEXT
ADDRESS
TEXT
CC_NO
NUMBER
NOT NULL
BANK_NAME
TEXT
NO_OF_TICKETS
NUMBER
30
DATA FLOWDIAGRAM
TESTING:
FORM NAME
INPUT
EXPECTED
OUTPUT
ACTUAL
OUTPUT
STATUS
MAIN MENU
FORM
Menu Option
Required form
must be displayed
Required
form was
displayed
Pass
TICKET
AVAILABILITY
FORM
Flight route or
Flight name
Flight seat
availability must
be displayed.
Flight seats
availability is
displayed.
Pass
RESERVATION
FORM
Personal
details were
entered.
Ticket must be
booked and
database updated.
Ticket was
booked and
database was
updated.
Pass
31
SAMPLE FORMS
MAIN MENU FORM
32
TICKET AVAILABILITY FORM RESERVATION FORM
CANCELLATION FORM
RESULT
Thus, the online Airline Reservations System was implemented using the specified front
end and back-end tools.
33
Ex No: 6 EMPLOYEE MANAGEMENT APPLICATION
PROBLEM DEFINITION
A payroll application is to be developed which is required to perform the following functions:
It must provide a user in employee mode with the details of an employee, which includes his
name, department, date of joining and salary.
It must validate a user to enter in administrator mode using password. It must provide a user
to enter in administrator mode to view or modify an employees details using his employee
ID. It must also allow the user to add a new employee and delete records of an existing
employee.
SRS DOCUMENT EMPLOYEE MANAGEMENTAPPLICATION
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in developing a system to
manage employee records.
The intended audience is any person who wants
To check employee details (both employee and administrator mode).
To add new employee, modify any employees details or delete records for the employee (only
administer mode).
Scope
The product is titled Employee Management Application (EMA).
The product will perform the following tasks
Allow either an employee or an administrator to view employee details.
Allow the administrator to add a new employee with corresponding details.
Allow the administrator to modify the detail of an employee.
Allow the administrator to delete the records for an employee.
Definitions, Acronyms and Abbreviations
EMA: Employee Management Application.
References
IEEE standard 830-1998 recommended practice for Software
Requirements Specifications-Description.
34
Overview
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Employee Management
System, product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and otherconstraints.
Succeeding pages illustrate the characteristics of typical naïve users accessing the system
along with legal and functional constraints enforced that affect Employee Management
Application in any fashion.
THE OVERALLDESCRIPTION
Product perspective
Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration that is on-line. This
makes it necessary to have a fast database system (such as any RDBMS) running on high
rpm hard-disk permitting complete data redundancy and backup systems to support the
primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to interact with
this software.
Software interfaces
Back End: MS Access2007
Front End: Microsoft Visual Basic 6.0
Memory Constraints
No specific constraints on memory.
Operations
The software allows two modes of operations
The administrator mode allows user to add a new employee, modify the existing
details of an employee, view the details of an employee and also delete records for an
existing employee.
Product Functions
Viewing the employee details
35
The user (both administrator and employee) must have the access to Upto-date information about
the employee including
Employee Id
EmployeeName
EmployeeDepartment
DateofJoining
Salary
Adding a new employee
The user (only in administrator mode) must be able to add a new employee by supplying the
following employee details.
EmployeeName
EmployeeDepartment
DateofJoining
Salary
Modifying the details of an employee
The user (only in administrator mode) must be able to modify the following details of an
existing employee.
EmployeeName
EmployeeDepartment
Date ofJoining
Salary
Usercharacteristics
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of abstraction that
allows easier, faster operation and reduces the knowledge requirement of enduser
The Product is absolutely user friendly, so the intended users can be the naïveusers.
The product does not expect the user to possess any technical background. Any person who
knows to use the mouse and the keyboard can successfully use thisproduct.
Constraints
At the time of adding a new employee, each employee must be assigned a unique ID
number.
SPECIFICREQUIREMENTS
Logical DatabaseRequirements
There is only one database which contains all the necessary information about an employee
which includes employee ID, employee name, department, date if joining and salary.
36
FRONT ENDDESCRIPTION
The front end for the Employee Management Application (EMA) is designed using
Microsoft Visual Basic 6.0. The front end contains a user friendly interface. It has a
welcome screen that provides an option for the user to enter in employee mode or in
administrator mode. In employee mode the user can enter the employee ID of the employee
and view his details. The user has to validate him self using password to enter in
administrator mode. In administrator mode, apart form viewing the details the user can also
add a new employee by providing details or modify the existing details using the employee
ID.
BACK ENDDESCRIPTION
There is only one table. It correlates a unique employee ID with his name, department,
date of joining and salary.
DATASTRUCTURES
EMPLOYEE DETAILS
FIELD NAME
TYPE
CONSTRAINTS
ID
AUTONUMBER
NOT NULL
NAME
TEXT
DEPT
TEXT
JOIN_DATE
DATE/TIME
SALARY
NUMBER
37
DATA FLOWDIAGRAM
TESTING:
FORM NAME
INPUT
EXPECTED
OUTPUT
ACTUAL OUTPUT
STATUS
MAIN MENU
Menu Option
Required form must
be displayed
Required Form was
displayed
Pass
ADD NEW
EMPLOYEE
Employee details
Add employee details
to database
Employee details was
updated to database
Pass
VIEW EMPLOYEE
DETAILS
Employee ID
Show employee
details
Employee details was
displayed
Pass
MODIFY
EMPLOYEE
DETAILS
Employee ID
Modify employee
Employee details was
modified
Pass
DELETE
EMPLOYEE
DETAILS
Employee ID
Delete employee
details
Employee details was
deleted from database
Pass
38
SAMPLE FORMS
MAIN MENU
ADD NEW EMPLOYEE
39
VIEW EMPLOYEE DETAILS
MODIFY EMPLOYEE DETAILS
40
DELETE EMPLOYEE DETAILS
RESULT
Thus, the Employee Management System was implemented using the specified front end
and back end tools.
41
Ex No: 7 HOSPITAL MANAGEMENT APPLICATION
PROBLEM DEFINITION
A hospital application is to be developed which is required to perform the following functions:
It must provide a user in admin mode with the details of a patient, doctor. It must provide a
user in doctor mode who can modify the details of the illness and the treatment.
SRS DOCUMENT HOSPITAL MANAGEMENTAPPLICATION
INTRODUCTION
Purpose
The purpose of this SRS is to describe the requirements involved in developing a system to
manage hospital records.
The intended audience is any person who wants To check patient and doctor
details (both doctor and administrator mode).
To add new treatment details for any particular patient according to his illness. (only doctor
mode).
Scope
The product is titled Hospital Management Application (HMA).
The product will perform the following tasks
Allow either an doctor or an administrator to view patient details. Allow the administrator to add
a new patient, doctor with corresponding details.
Allow the administrator to modify the detail of an patient, doctor. Allow the doctor to add the
records for an ongoing treatment.
Definitions, Acronyms and Abbreviations HMA: Hospital Management
Application.
References:
IEEE standard 830-1998 recommended practice for Software
Requirements Specifications-Description.
42
Overview
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Hospital Management
System, product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and other constraints.
Succeeding pages illustrate the characteristics of typical naïve users accessing the system
along with legal and functional constraints enforced that affect Hospital Management
Application in any fashion.
THE OVERALLDESCRIPTION
Product perspective
Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration that is on-line. This
makes it necessary to have a fast database system (such as any RDBMS) running on high
rpm hard-disk permitting complete data redundancy and backup systems to support the
primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to interact with
this software.
Software interfaces
Back End: MSAccess
Front End: Microsoft Visual Basic 6.0
Memory Constraints
No specific constraints onmemory.
Operations:
The software allows two modes of operations
The administrator mode allows user to add a new patient, doctor, modify the
existing details of a patient & doctor, view the details of an Patient &doctor.
43
Product Functions
Patient Details
The user (both administrator and doctor) must have the access to Up-to-date information about
the patient including.
PatientID
PatientName
PatientAge
PatientAddress
Admit and DischargeDate
DoctorDetails
The user (only in administrator mode) must be able to add and view by supplying the
following doctor details.
Doctor ID
DoctorName
DoctorAge
DoctorAddress
DoctorQualification
Illness Details
The user (only in doctor mode) must be able to modify the following details of an existing
treatment.
PatientID DoctorID
Illness
Medication
User characteristics
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of abstraction that
allows easier, faster operation and reduces the knowledge requirement of enduser
The Product is absolutely user friendly, so the intended users can be the naïveusers.
The product does not expect the user to possess any technical background. Any person who
knows to use the mouse and the keyboard can successfully use thisproduct.
Constraints
At the time of adding a new patient and doctor, each must be assigneda unique IDnumber.
44
The ID numbers for the illness table must match the IDs in the respectivetables
SPECIFICREQUIREMENTS
Logical DatabaseRequirements
There is one database which contains all the necessary information about a patient which
includes patient ID, patient name, age, address, admit and discharge date
There is a database which contains all the necessary information about a doctor which
includes doctor ID, doctor name, age, address, qualification.
There is a database which contains all the necessary information about a treatment which
include Patient ID, doctor ID, illness, medication
FRONT ENDDESCRIPTION
The front end for the Hospital Management Application (HMA) is designed using
Microsoft Visual Basic 6.0. The front end contains a user friendly interface. It has a
welcome screen that provides an option for the user to enter in doctor mode or in
administrator mode. The user has to validate himself using password to enter in
administrator mode. In administrator mode, apart from viewing the details the user can also
add a new patient and doctor by providing details or modify the existing details using the
patient ID and doctorID.
BACK ENDDESCRIPTION
There are 4 tables. The 1
st
one maintains login details for all the users. The 2
nd
table
correlates a unique patient ID with his name, age, address, admit and discharge date.. The
3rd table correlates a unique doctor ID with his name, age, address and qualification. The 4
th
table correlates a doctor ID and patient ID with illness and medication
DATASTRUCTURES
LOGINDETAILS
FIELD NAME
TYPE
CONSTRAINTS
ID
NUMBER
NOT NULL
PASSWORD
TEXT
NOT NULL
45
PATIENTDETAILS
FIELD NAME
TYPE
CONSTRAINTS
ID
NUMBER
NOT NULL
FNAME
TEXT
NOT NULL
LNAME
TEXT
AGE
TEXT
ADDRESS
TEXT
INDATE
DATE/TIME
OUTDATE
DATE/TIME
DOCTORDETAILS
FIELD NAME
TYPE
CONSTRAINTS
ID
NUMBER
NOT NULL
FNAME
TEXT
NOT NULL
LNAME
TEXT
AGE
NUMBER
ADDRESS
TEXT
QUALIFICATION
TEXT
46
TREATMENTDETAILS
FIELD NAME
TYPE
CONSTRAINTS
PID
NUMBER
NOT NULL
DID
NUMBER
NOT NULL
ILLNESS
TEXT
MEDICINE
TEXT
E/RDIAGRAM
47
TESTING
FORM NAME
INPUT
EXPECTED
OUTPUT
ACTUAL
OUTPUT
STATUS
LOGIN FORM
ID and Password
If correct password,
main menu must be
If correct
password, main
menu was
Pass
displayed
displayed
MAIN MENU
FORM
Menu Option
Required Form must
be
Required Form
must be
Pass
displayed
displayed
PATIENT
DETAILS FORM
Patient ID or
Patient details
Patient details must be
displayed or updated
to database.
Patient details
was displayed or
updated to
database
Pass
DOCTOR
DETAILS
Doctor ID
Doctor details must be
Doctor details
was displayed
Pass
FORM
displayed
TREATMENT
DETAILS FORM
Patient ID,
Treatment details
must be updated to
database
Treatment
details was
updated to
database
Pass
Doctor ID,
Illness and
Medicines
48
SAMPLE FORMS
LOGIN FORM
MAIN MENU FORM
49
PATIENT DETAILSFORM
DOCTOR DETAILSFORM
50
TREATMENT DETAILS FORM
RESULT
Thus, the Hospital Management System was implemented using the specified front end and
back-end tools.
51
Ex No: 8 DEVELOPMENTS OF A BLOOD BANK MANAGEMENT SYSTEM
Blood bank is a place where blood bag that is collected from blood donation events is stored in
one place. The term blood bank” refers to a division of a hospital laboratory where the storage
of blood product occurs and where proper testing is performed to reduce the risk of transfusion
related events.
Online Blood Bank management system is to provide services for the people who need blood by
getting help from the donors who are interested in donating blood for the people. Blood Bank
donation system can collect blood from many donators in short from various sources and
distribute that blood to needy people who require blood. To do all this we require high quality
Web Application to manage those jobs.
Problem Statement
1. The first problem is to search for blood donation records. Staffs of the hospital have to
search one-by-one and it may take a lot of time. Besides that, the paper records can be
lost or undefined.
2. Location of blood donation campaign and planning. Donor usually heard the location for
blood donation campaign from friends or family and cannot plan well for next
donation.
3. The staffs of the hospitals are having difficulty to make report for total blood packet by
monthly basis. Missing and duplicate blood donation information records make the
count inaccurate and this will be problem to detect critical blood demand
4. One of the factors of the public afraid to donate their blood is they believe in myths. The
myths that they always believe are, if they donate their blood they will become weak
and pale. This system hopes to solve that problem by creating more awareness of the
process of blood donation.
System Requirement Specification (SRS)
Purpose:
The main purpose of this application is to automate the complete operations of the blood bank.
The intended audience is anyone working at a bloodbank who wants to keep track and maintain
blood donation records Scope:
The product is titled Blood Bank Management System (BBMS) The product will perform the
following tasks:
Allow users to register for blood donation
Allow admin to maintain blood donation records of various different donors and blood group in
a single system.
Allows super admin to manage admins so that there is no abuse of power.
Definitions, Acronyms and Abbreviations:
BBMS Blood Bank Management System
52
References:
IEEE standard 830-1998 recommended practice for Software Requirements Specifications-
Description.
IEEE Software Requirements Specifications
Templatehttp://www.cas.master.ca/~carette/SE3M04/2003/files/ srs_template.doc
Overview:
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Blood Bank Management
System, product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and other constraints.
Succeeding pages illustrate the functions of typical users accessing the system along with the
different functions available for the admins and super admins and the responsibilities they
must share to make proper and efficient use of the Blood Bank Management System.
Hardware and Software Requirements Hardware Requirements:
Processor
:
Intel Core Duo 2.0 GHz or more
RAM
:
1 GB or More
Hard disk
:
80GB or more
Monitor
:
15” CRT, or LCD monitor
Keyboard
:
Normal or Multimedia
Mouse
:
Compatible mouse
Software Requirements:
i. XAMPP (Cross Platform(X) for Apache, MySQL, PHP and Perl)
ii. Notepad iii. Google Chrome or Mozilla Firefox or Internet Explorer
Languages Used:
Front End : PHP, HTML, CSS
Back End : MySQL Database Server
Operating System : Windows 7 or above
53
FRONT-END DESCRIPTION
The proposed system (Blood Bank Management System) is designed to help the Blood
Bank administrator to meet the demand of Blood by sending and/or serving the request for Blood
as and when required. The proposed system gives the procedural approach of how to bridge the
gap between Recipient, Donor, and Blood Banks. The system has a registration process wherein
the user can register as a Donor. The system will provide the admin the option to look at the
details of the Donor and verify the integrity of the user before either accepting or rejecting the
user. The administrator can also alter all the system data. The Super Admin feature has been
added to manage and control all admins so that there is no abuse or corruption of power.
BACK-END DESCRIPTION
There are 7 tables. The 1st table contains admin details such as username and password.
The 2nd table contains information about blood donation camps. The 3rd table contains the user
queries that are sent to the admin. It contains details such as name, email, mobile, subject and
date. The 4th table contains the details of the registered blood donors. The 5th table contains the
login credentials of the super admins whose main function is to manage the other admins. The 6
th
table contains the blood requests made by the recipients or hospitals. The req id is the primary
key of the table and it is also auto incremented for every entry in the table. The 7th table contains
all the blood groups. The bg attribute is also the primary key.
DATA STRUCTURE
Admin (admin):
Attributes
Data Type
Constraints
Username
varchar(100)
NOT NULL
Pwd
varchar(100)
NOT NULL
Adminname
varchar(100)
NOT NULL
54
Camps (camp):
Attributes
Data Type
Constraints
camp id
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Campname
varchar(500)
NOT NULL
Organisedby
varchar(500)
NOT NULL
City
varchar(100)
NOT NULL
State
varchar(100)
NOT NULL
Detail
varchar(1000)
NOT NULL
Contact Us (contacts):
Attributes
Data Type
Constraints
Name
varchar(100)
NOT NULL
Email
varchar(100)
NOT NULL
Mobile
varchar(100)
NOT NULL
Subj
varchar(100)
NOT NULL
Date
timestamp(5)
NOT NULL
Donors (registereddonors):
Attributes
Data Type
Constraints
Donorid
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Name
varchar(100)
NOT NULL
Gender
varchar(10)
NOT NULL
Age
int(3)
NOT NULL
Mobile
varchar(10)
NOT NULL
b_g
varchar(15)
NOT NULL
Email
varchar(100)
NOT NULL
City
varchar(100)
NOT NULL
55
Super Admin (superadmin):
Attributes
Data Type
Constraints
Username
varchar(100)
NOT NULL
Pwd
varchar(100)
NOT NULL
Adminname
varchar(100)
NOT NULL
Blood Request (requests):
Attributes
Data Type
Constraints
Reqid
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Name
varchar(100)
NOT NULL
Gender
varchar(100)
NOT NULL
Age
int(3)
NOT NULL
Mobile
varchar(13)
NOT NULL
Bg
varchar(15)
NOT NULL
Email
varchar(100)
NOT NULL
Deadline
date
NOT NULL
Detail
varchar(500)
NOT NULL
Blood Group (bloodgroup):
Attributes
Data Type
Constraints
Bg
varchar(100)
NOT NULL
DATA FLOW DIAGRAM (DFD) LEVEL 0 DFD:
56
LEVEL 1 DFD:
LEVEL 2 DFD:
57
E-R DIAGRAM FOR BLOODBANK:
The E-R Diagram defines 6 different entities and their attributes along with the relationship
between these entities. The entities are Donor, Blood, Blood Bank, Admin, Super Admin and
Recipient. The relationship between these entities are as follows:
Donor donates Blood
Blood Bank Stores Blood
Recipient receives Blood
Admin Manages Blood Bank
Super Admin Manages Admin
gender
age
mobile
no
Blood
group
name
Donor
donate
Blood
city
blood
group
stores
password
username
m
A
a
d
n
m
a
g
i
n
e
s
manages
Blood
Bank
details
deadline
Super
Admin
username
password
name
age
receives
Recipient
gender
mobile
no
58
59
CLASS DIAGRAM:
60
Sample Forms:
Donor Registration Page:
Request Blood Page:
61
Camps Page:
Contact Us Page:
62
About Us Page:
Admin Log in Page:
63
The Donors Page:
View Requests Page:
64
65
Ex No: 9 COVID PATIENTS MANAGEMENT SYSTEM
PROBLEM DEFINITION This Application is developed to fight the Corona situation
together and stronger.
The COVID Patients Management System is useful for automating the Data Collection of
COVID affected patients and have a track on them.
Doctors/Specialists can enter the details of the patient who has been affected by COVID.
The details include Patient Name, Age, Sex, Mobile number, Address, Date of test,
Doctor.
The Doctors will get an alert once in 15 days in order to track the patient if the age is
less than 35 and 7 days if the age is more than 35. This will help the doctors to have a
Health track on the patients.
The patient will get an automated alert via SMS reminding them to take proper medicine
an diet plan and after the verification of complete curation of the Patient, their data will
automatically be sent to inactive history database
SYSTEM REQUIREMENT SPECIFICATION (SRS)
Purpose:
The main purpose of this application is to automate the complete operations of the
Hospital in managing Covid Patient Database.
The intended audience is anyone working at a hospital who wants to keep track and
maintain Covid Patient records
Scope:
1. The product is titled COVID Patients Management system
2. The product will perform the following tasks:
a. Allow doctors to register
b. Allow admin/doctor to maintain Patient records of Covid Test and
3. relevant details
a. Triggers and alert to the doctor 15 days/ 7 days once dependant on the age
4. of the patient
Definitions, Acronyms and Abbreviations:
1. CPMS COVID Patient Management System
Overview:
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the COVID Patient
Management System, product perspective, hardware interfaces, software interfaces,
66
communication interface, memory constraints, product functions, user characteristics
and other constraints.
Succeeding pages illustrate the functions of typical users accessing the system along with
the different functions available for the admins and doctors of the hospital.
Hardware and Software Requirements
Hardware Requirements:
Processor : Intel Core Duo 2.0 GHz or more
RAM : 1 GB or More
Hard disk : 40GB or more
Monitor : 15” CRT, LCD or LED monitor
Keyboard : Normal or Multimedia Mouse
: Compatible mouse
Software Requirements:
XAMPP (Cross Platform(X) for Apache, MySQL, PHP and Perl)
Notepad
Google Chrome or Mozilla Firefox or Internet Explorer
Languages Used:
Front End
: PHP, HTML, CSS
Back End
: MySQL Database Server
Operating System
: Windows 7 or above
FRONT-END DESCRIPTION
The proposed COVID Patients Management System is useful for automating the Data
Collection of COVID affected patients and have a track on them.Doctors/Specialists can
enter the details of the patient who has been affected by COVID. The details include
Patient Name, Age, Sex, Mobile number, Address, Date of test, Doctor.The Doctors will
get an alert once in 15 days in order to track the patient if the age is less than 35 and 7
days if the age is more than 35. This will help the doctors to have a Health track on the
patients.The patient will get an automated alert via SMS reminding them to take proper
medicine an diet plan and after the verification of complete curation of the Patient, their
data will automatically be sent to inactive history database
67
BACK-END DESCRIPTION
There are 4 tables. The 1
st
table contains Admin/Doctor details such as username
and password. The 2
nd
table contains information about COVID patientssuch as name,
email, mobile,ID,age and date. The 3
rd
table contains the details of the Diet Plans for a
Patient and SMS Management. The 4
th
table contains the Cured Patients database. Primary
key is the Patient ID.
DATA STRUCTRURE
Doctor/Admin :
Attributes
Data Type
Constraints
Username
varchar(100)
PRIMARY KEY
Pwd
varchar(100)
NOT NULL
Ad/docname
varchar(100)
NOT NULL
Covid Patient :
Attributes
Data Type
Constraints
Name
varchar(100)
NOT NULL
Email
varchar(100)
NOT NULL
Mobile
varchar(100)
NOT NULL
Age
varchar(100)
NOT NULL
Date Admitted
timestamp(5)
NOT NULL
PID
varchar(100)
PRIMARY KEY
Diet Plan :
Attributes
Data Type
Constraints
PID
varchar(100)
PRIMARY KEY
Breakfast
varchar(100)
NOT NULL
Lunch
varchar(100)
NOT NULL
Dinner
varchar(100)
NOT NULL
68
Cured Patient :
Attributes
Data Type
Constraints
Name
varchar(100)
NOT NULL
Email
varchar(100)
NOT NULL
Mobile
varchar(100)
NOT NULL
Age
varchar(100)
NOT NULL
Date Admitted
timestamp(5)
NOT NULL
PID
varchar(100)
PRIMARY KEY
ER DIAGRAM
DATA FLOW DIAGRAM
LEVEL 0 DFD
69
LEVEL 1 DFD
LEVEL 2 DFD
70
SAMPLE SCREENSHOTS
71
72
73
Ex No: 10 RESTAURANT TABLE MANAGEMENT SYSTEM
Restaurant table management system is a application where a customer can pre-book a
table and also will be able to pay their bills through online payment.
In The other end the Hotel management will be able to promote their restaurant and will
receive the customer needs and also the table reservations can be done
Problem Statement
1. The application is useful for the restaurants to provide the customers with the seamless
billing and reservation experience
2. The hotel management team or the manager will be able to look for a free table from
the application once when the customers enter the restaurant and can assign them with
a table free with respect to their group strength
3. The server for that particular table will be able to get the order and will be able to feed
the dishes ordered by the members of the table and will be saved in the database of
that particular table. The server or the management will be able to add or edit the menu
with respect to the members decision
4. Once when the meal is done, the bill will be auto generated once when the server or
the management team clicks on end session and will provide the final bill amount. The
server will then set the table's status to "under cleaning "and once when it is done, the
table will will be back to available status and can be assigned to other customers
entering the restaurant.
System Requirement Specification (SRS)
Purpose:
The main purpose of this application is to automate the complete operations of the
Restaurant table Management.
The intended audience is anyone working at a Restaurant who wants to keep track
and maintain Table booking.
Scope:
The product is Restaurant Table Management System (RTMS) The product will
perform the following tasks:
Allow users to book the table
Allow admin to maintain reservation of tables from different customers and
pay the bill in a single system.
Allows super admin to manage admins so that there is no abuse of power
.Definitions, Acronyms andAbbreviations:
RTMS Restaurant Table Management System
74
References:
IEEE standard 830-1998 recommended practice for
Software
RequirementsSpecifications-Description.
IEEE Software Requirements Specifications
Templatehttp://www.cas.master.ca/~carette/SE3M04/2003/files/ srs_template.doc
Overview:
The SRS contains an analysis of the requirements necessary to help easy design.The
overall description provides interface requirements for the Restaurant Table
Management System, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user characteristics
and otherconstraints.
Succeeding pages illustrate the functions of typical users accessing the system along with
the different functions available for the admins and super admins and the
responsibilities they must share to make proper and efficient use of the Restaurant
Table Management System.
Hardware and Software Requirements Hardware Requirements:
Processor : Intel Core Duo 2.0 GHz or more
RAM : 1 GB or More
Hard disk : 80GB or more
Monitor : 15” CRT, or LCD monitor
Keyboard : Normal or Multimedia
Mouse : Compatible mouse
Software Requirements: iv. XAMPP (Cross Platform(X) for Apache, MySQL, PHP
and Perl)
v. Notepad vi. Google Chrome or Mozilla Firefox or Internet Explorer
75
Languages Used:
Front End
: PHP, HTML, CSS
Back End
: MySQL Database Server
Operating System
: Windows 7 or above
FRONT-END DESCRIPTION
The proposed system (Restaurant Table Management System) is designed to help
the customers book the table and pay the bill . The proposed system gives the procedural
approach of how to bridge the gap between Customer, hotel management and bank . The
system has a registration process wherein the user can register as a Customer. The system
will provide the admin the option to look at the details of the customer and verify the
integrity of the hotel management before either accepting or rejecting the table reservation.
The administrator can also alter all the system data. The Super Admin feature has been
added to manage and control all admins so that there is no abuse or corruption of power.
BACK-END DESCRIPTION
There are 7 tables. The 1st table contains admin details such as username and
password. The 2nd table contains information about Registered Restaurants. The 3rd
table contains the user queries that are sent to the admin. It contains details such as name,
email, mobile, subject and date. The 4th table contains the details of the registered
Customers . The 5th table contains the login credentials of the super admins whose main
function is to manage the other admins. The 6
th
table contains the Food requests made by
the customer and Restaurants. The req id is the primary key of the table and it is also auto
incremented for every entry in the table. The 7th table contains all the nearby available
hotels. The bg attribute is also the primary key.
DATA STRUCTURE
Admin (admin):
Attributes
Data Type
Constraints
Username
varchar(100)
PRIMARY
INCREMENTKEY(AUTO)
Pwd
varchar(100)
NOT NULL
Adminname
varchar(100)
NOT NULL
76
Restaurant Names (Hotel):
Attributes
Data Type
Constraints
Restaurant ID
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Restaurant name
varchar(500)
NOT NULL
Manager name
varchar(500)
NOT NULL
City
varchar(100)
NOT NULL
State
varchar(100)
NOT NULL
Detail
varchar(1000)
NOT NULL
Contact Us (contacts):
Attributes
Data Type
Constraints
Name
varchar(100)
NOT NULL
Email
varchar(100)
NOT NULL
Mobile
varchar(100)
PRIMARY
KEY(AUTO
INCREMENT)
Subj
varchar(100)
NOT NULL
Date
timestamp(5)
NOT NULL
Customors (registeredcustomers):
Attributes
Data Type
Constraints
Customerid
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Name
varchar(100)
NOT NULL
Gender
varchar(10)
NOT NULL
Age
int(3)
NOT NULL
Mobile
varchar(10)
NOT NULL
b_g
varchar(15)
NOT NULL
Email
varchar(100)
NOT NULL
City
varchar(100)
NOT NULL
77
Super Admin (superadmin):
Attributes
Data Type
Constraints
Username
varchar(100)
PRIMARY
KEY
AUTO
INCREMENT)
Pwd
varchar(100)
NOT NULL
Adminname
varchar(100)
NOT NULL
Table Reservation (Pre booking table ):
Attributes
Data Type
Constraints
Reqid
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Name
varchar(100)
NOT NULL
Gender
varchar(100)
NOT NULL
Age
int(3)
NOT NULL
Mobile
varchar(13)
NOT NULL
Headcount
int(3)
NOT NULL
Email
varchar(100)
NOT NULL
Deadline
date
NOT NULL
Detail
varchar(500)
NOT NULL
DATA FLOW DIAGRAM (DFD) LEVEL 0 DFD:
78
LEVEL 1 DFD
LEVEL 2 DFD
E-R DIAGRAM FOR TABLE MANAGEMENT SYSTEM:
The E-R Diagram defines 6 different entities and their attributes along with the relationship
between these entities. The entities are Cashier, Customer, Chef, Taken by, Waiter,
Restaurant.
The relationship between these entities are as follows:
Customer reserves Table
Restaurant receives the order
Confirms the table
Waiter Manages the order
Waiter serves the food
79
Customer pays the bill
7. Sample Forms
80
81
Ex No: 11 EVENT MANAGEMENT SYSTEM
Event management is the application of project management to the Creation and
Development of large scale events such as festivals, Wedding ceremonies, formal parties.
People that are need to find or book online event halls and or willing to see the packages
and timing slots online about halls. They will able to get all this information through this
system. To get success in the event management business, user should have strong network
contacts of service provider. These contacts are essentially providers of specific services
who can be mobilized quickly to participate in any given event. To make an event
successful event Manager needs different service provider like Sound systems services,
Lighting providers, Canteen services, stage construction and so on.
Problems statement:
In any event many service providers work simultaneously and it is very hard to manage
these providers.
It is also important for event organizer that he has all the contacts details of these service
Providers so that he can contact them any time to plan an event at given time.
In present system Event Company has to do all management work manually.
They keep all payment information on papers.
There is no system to check the past expenses on any event.
To do this they have to check payment register
This task is very time consuming and tiresome.
so this system helps the event management company to manage their paper work online
and they
can also retrieve report of last event they have completed
Dependencies/ External Systems
Following are the tools / technologies, on which our system depends for its completion,
Programming language: PHP
Front-End: HTML, CSS, BOOTSTRAP(framework of CSS ANS JS)
Hardware interface: 512 MB RAM, WINDOWS 7/8
Database: MySql
XAMPP (Apache MySql PHP)
MySQL server is an open source relational database management system
which is used to store the database using SQL queries. In this project data
of halls, wedding lawns and data of accounts are stored in it. Tools: Visual
Studio
82
Frame work: MVC
MVC (Model View Controller) is used for implementing user interface on computers.
Product:
cyber cash
The CyberCash Secure Payment System is a complete system for conducting financial
transactions on the Internet. It accepts both credit card payments and cash/coin
transactions. The CyberCash system is a great solution for any Web site that wants to
accept electronic payment for goods or services
Requirements
Functional
Requirement
Registration:
To enter into this site user has to register himself first.
Requirements of registration are first name, last name,
user name, email-id, password, confirm password etc.
User Login:
The System provides facility to login into the system.
Enter username and password
User Profile page
Select the Event:
The user can select the event and also select payment method.
Forgot Password
The user can send reset link to the mail id to reset password.
Input: Email id
Output: Reset link send to Email id.
Logout:
The system provides the facility to logout from the site
Input : Select logout option
Output : Logout from the system
Processing : User will logout
Online packages:
Online various payment packages will available to see.
83
Time Slots:
Time slots for availability of a place or venue on which event going too held.
Notification/updates:
User will get to know any notification, recent update or important massages through e-
mail.
Non-Functional
Requirement 1.
Performance
Requirements:
The system need to be reliable
If unable to process the request then appropriate error message
Web pages are loaded within few seconds
2. Safety Requirements:
The details need to be maintained properly
Users must be authenticated The database must be kept backed up
3. Security Requirements:
After entering the password and user id the user
can access his profile
The details of user must be safe and secure
Sharing of details Data Requirements:
Minimum 1GB needed to store our database.
512MB RAM is also needed to install our whole system.
External Requirements:
How will our system connect to other software/components?
External requirements are following;
To get important notification through E-mail, user must have to provide and email
address.
For online payment; for example using cyber cash customer will provide account
number.
84
DATA FLOW DIAGRAM
Data Flow Diagram level 0:
Data Flow Diagram level 1:
85
Data Flow Diagram Level 2
Data Dictionary User:
ATTRIBUTES
DATA TYPE
CONSTRAINTS
U_id
Varchar(100)
PRIMARY KEY
U_Name
Varchar(100)
Not null
U_Contact
Varchar(100)
Not null
U_Location
Varchar(100)
Not null
U_Email
Varchar(100)
Not null
86
User Request:
Name
Data Type
CONSTRAINTS
UR_Categories
Varchar(100)
NOT NULL
UR_Service
Varchar(100)
NOT NULL
UR_Location
Varchar(100)
NOT NULL
Account:
Name
Data
Type
Constraints
AC_ID
Integer(4)
PRIMARY
KEY
AC_Password
String(30)
NOT NULL
AC_Email
String(20)
NOT NULL
Admin:
Name
Data
Type
Constraints
AD_ID
Integer(5)
PRIMARY
KEY
AD_Name
String(30)
NOT NULL
AD_Password
String(25)
NOT NULL
87
SCREEN SHOTS:
Home:
User login
88
Change password
Add sponsor:
89
90
91
92
93
Ex No: 12 CRIME REPORTING SYSTEM
ABSTRACT:
The aim of the project is to develop an online crime report and managing system which is
easily accessible to the public.
This System registers the complaints from people through online and it will also helpful
to police department in catching criminals, in system and person can give any
complaint at any time.
PROBLEM STATEMENT:
This Application is used to develop a web based program using which people can report
crime on online.
There will be an ‘SOS ’capability in which, the user can press a button and his/her
location will be sent to the nearest Police station.
There will be a separate component for the accident victims so that FIR will be registered
fast and treatment will be started as soon as possible.
In the current system user information will be kept confidential and users complain will
be forwarded to the nearest police station.
It will search the address using IP address and then forwards the message to the police
location from where the message has been received.
We intend to create a project which will helps to bridge the gap between the police
department and the common man.
The main site will be maintained by the admin (from the police) who will then notify the
user if the FIR has been registered and the necessary action has been taken.
SYSTEM REQUIREMENT SPECIFICATION (SRS):
Purpose:
The main purpose of this application is to automate the complete operations of the
Crime Reporting System. The intended audience is anyone working at a Crime
Reporting System who wants to keep track and maintain the Crime records
Scope:
The product is titled Crime Reporting System System
(CRS) The product will perform the following tasks:
Allow users to register for Complaints.
Allow admin to maintain the records of various different users and action taken by the
police officers in a single system.
94
Allows super admin to manage admins so that there is no abuse of power.
Definitions, Acronyms and Abbreviations:
CRS Crime Reporting System(CRS)
Overview:
The SRS contains an analysis of the requirements necessary to help easy design.
The overall description provides interface requirements for the Crime Reporting System,
product perspective, hardware interfaces, software interfaces, communication interface,
memory constraints, product functions, user characteristics and otherconstraints.
Succeeding pages illustrate the functions of typical users accessing the system along with
the different functions available for the admins and super admins and the
responsibilities they must share to make proper and efficient use of the Crime
Reporting System
Hardware and Software Requirements
Hardware requirements:
The database connectivity requires a hardware configuration that is on-line. This makes it
necessary to have a fast database system running on high rpm hard disk permitting
complete data redundancy and back-up systems to support the primary goal of reliability.
Processor : Intel Core Duo 2.0 GHz or more
RAM : 1 GB or More
Hard disk : 80GB or more
Monitor : 15” CRT, or LCD monitor
Keyboard : Normal or Multimedia
Mouse : Compatible mouse
Software Requirements: vii. XAMPP (Cross Platform(X) for Apache, MySQL, PHP
and Perl)
viii. Notepad ix. Google Chrome or Mozilla Firefox or Internet Explorer
Languages Used:
Front End
: PHP, HTML, CSS
Back End
: MySQL Database Server
Operating System
: Windows 7 or above
95
FRONT-END &BACK-END DESCRIPTION
FRONT-END DESCRIPTION:
The proposed system (Crime Reporting System) is designed to help the Crime Reporting
administrator to meet the sending and/or serving the request for complaints as and when
required. The proposed system gives the procedural approach of how to bridge the gap
between public, police officer, and the admin. The system has a registration process
wherein the user can register to raise the complaints. The system will provide the admin
the option to look at the details of the complaints and verify the integrity of the user before
either accepting or rejecting the user. The administrator can also alter all the system data.
The Super Admin feature has been added to manage and control all admins so that there is
no abuse or corruption of power.
BACK-END DESCRIPTION:
There are 9 tables. The 1
st
table contains User details such as username, password and so
on.The 2nd table contains the details of users first information report(FIR) that are sent to
the admin. The 3rd table contains the details of users about the missing person. The 4th
table contains admins login details. The 5th table contains the admins response for the user
report.The 6th table contains police officer login details. The 7th table contains the officer's
response for the user report to the admine and the user.The 8th table contains police officer
login details. The 9th table contains the officer's response for the user report to the admine
and the user.
DATA STRUCTURE:
USER DETAILS:
Attributes
Data Type
Constraints
Report ID
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
User ID
varchar(100)
FOREIGN KEY
Phone Number
varchar(100)
NOT NULL
Email ID
varchar(100)
NOT NULL
Address
varchar(100)
NOT NULL
Aadhar card number
varchar(100)
NOT NULL
City
varchar(100)
NOT NULL
96
FRIST INFORMATION REPORT :
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY KEY(AUTO
INCREMENT)
Complaint ID
varchar(100)
FOREIGN KEY
Username
varchar(100)
NOT NULL
Report Details
varchar(100)
NOT NULL
Address
varchar(100)
NOT NULL
Date and time of
the Incident
Datetime
NOT NULL
Picture/Vedio
upload
varchar(100)
NOT NULL
Phone No
varchar(100)
NOT NULL
City
varchar(100)
NOT NULL
MISSING PERSON REPORT :
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY KEY(AUTO
INCREMENT)
Name
varchar(100)
NOT NULL
Complaint ID
varchar(100)
FOREIGN KEY
Age
varchar(100)
NOT NULL
Missing date
varchar(100)
NOT NULL
Contact no
varchar(100)
NOT NULL
Alter contact
no
varchar(100)
NOT NULL
Picture/Video
upload
varchar(100)
NOT NULL
City
varchar(100)
NOT NULL
Police Officer (login):
Attributes
Data Type
Constraints
Username
varchar(100)
NOT NULL
Officer ID
varchar(100)
NOT NULL
Password
varchar(100)
NOT NULL
97
Police Officer Page:
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
User Name
varchar(100)
NOT NULL
Action Taken
varchar(100)
NOT NULL
Status Upload
varchar(100)
NOT NULL
Contact No
varchar(100)
NOT NULL
Message
varchar(200)
NOT NULL
Admin (login):
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Email ID
varchar(100)
NOT NULL
Password
varchar(100)
NOT NULL
Admin Page:
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY
KEY(AUTO
INCREMENT)
Police
Officer ID
varchar(100)
FOREIGN KEY
Status of
Report
varchar(100)
NOT NULL
Contact No
varchar(100)
NOT NULL
Message
varchar(200)
NOT NULL
98
Supreme Admine (details):
Attributes
Data Type
Constraints
Name
varchar(100)
NOT NULL
Password
varchar(100)
NOT NULL
Officer ID
varchar(100)
NOT NULL
Supreme Admine (page):
Attributes
Data Type
Constraints
Report No
int(100)
PRIMARY KEY(AUTO
INCREMENT)
Admin ID
varchar(100)
NOT NULL
Status
varchar(100)
NOT NULL
Message
varchar(200)
NOT NULL
DATA FLOW DIAGRAM(DFD):
LEVEL 0 DFD:
95
Supre
me
admin
ADMIN
Police
Officer
User/Public
99
LEVEL_1_DFD:
view/updat
e
edit/view/updat
estatus
LOGI
LOGI
POLICE
LOG
IN
Admin
complaint
details
upload
action
Follow
up
the
pending
view
complaint
LOG
OUT
LOG
OUT
LEVEL
2
DFD:
User
LOG
IN
Pending
report
Complaints
report
Action
taken
details
Follow
up
the
pending
LOG
OUT
100
CITIZEN/USERS :
The Users has the permission to add complaint, crime report, missing person details, edit
account, see complaint status send message and also change password.
101
Admin Features :
Admin has the permission to see users, block users, see user complaints, crimes & can
reply. He /She can add, delete, update and view the most wanted persons, missing
persons, emergency complaint, complaints status, query, feedback and change
password
102
Police Officer:
By Login the police officer can view the complaints, update the complaint status and the
emergency complaints. Also he/she can Inquire the complaint.
CONCLUSION:
The automated Reporting System is more functional because of people automatically can
report crimes around them in picture or video format to the crime authority .
RESULT:
Thus, the Crime Reporting System was implemented using the specified front end and back
endtool.
103
Ex No: 13 BOOK RESALE APPLICATION
PROBLEM DEFINITION
There are many peoples who are interested in reading books. However, not many of them
are regular in reading books because the new books are costly This project is aimed to
developing an Online old used book information. This project Book management System
explains about how Book Shops works with the computer application when any customers
buy books from the store. Book management system is a project which aims in developing
a computerized system to maintain all the books. Books can be searched by their Title,
Description or Author and also books can be seen in appropriate categories. Each book is
added with a unique Identification number and other details including a Shelf Number
which helps to locate the book. We can also use Google Books to fetch details of a book
from Internet. A cover image and PDF eBook can also be attached with the Book details.
The Books can be issued and Submitted in a fast manner. The Library members can be
managed more efficiently. We can easily get information like who took a particular book or
which are the books taken by a specific Library members
INTRODUTION
In the world of software development there lots of improvement in the area of
Architectural design and principles. The philosophies and implementation details are
changing as the people guiding the development of the application. In this fantastic and yet
sometimes complex world of software development there are some tried and true
architecture patterns and software development guidelines employed by most architects.
Also your design must have an ability to turn towards innovation instead of lending itself
to common practices. Web services are one such area where architects must lean on their
creative side and hope that their solutions are still successful. In this report we will explain
an exciting voyage down the road of Web services application. From requirements to use
cases, to database design, to component frameworks, to user interfaces, we will cover each
and every aspect of system design required to build an application with collaborative Web
services. The reason why we selected online Bookstore web service is everybody walking
down the street has some idea about bookstores. The objective of this project is to develop
an ebook store where books can be bought from the comfort of home through the Internet.
An online book store is a virtual store on the Internet where customers can browse the
catalog and select books of interest. The selected books may be collected in a shopping
cart. At checkout time, the items in the shopping cart will be presented as an order. At that
time, more information will be needed to complete the transaction. Usually, the customer
will be asked to fill or select a billing address, a shipping address, a shipping option, and
payment information such as credit card number. An email notification is sent to the
customer as soon as the order is placed.
SYSTEM REQUIREMENT
Below are the tools, languages and software that were used to develop a Book Resale
Application System:
104
HARDWARE REQUIREMENTS
System : Pentium IV 2.4 GHz.
Hard Disk : 40 GB.
Floppy Drive : 1.44 Mb.
Monitor : 15 VGA Colour.
Mouse : Logitech.
Ram : 512 Mb.
SOFTWARE REQUIREMENTS
Operating system : Windows XP.
Coding Language : JAVA
Data Base : MYSQL
IDE : Net Beans
DATA FLOW DIAGRAM
LEVEL 1:
OWNER
CUSTOMER
DATABASE
LEVEL2
:
OWNER
N
L
H
o
J
g
K
o
N
u
t
H
Upload
Data
Login
SEND
MAIL
105
Level 3:
Level 4:
Send
Key
to
User
USER
Add
to
cart
Registration
LOGOUT
View
book
Login
LOGIN
view
book
View
history
Add
book
LOGOUT
Admin
Buy
Login
View
categort
Search
book
Add
cart
Logout
Customer
106
TESTING
System Testing
The purpose of testing is to discover errors. Testing is the process of trying to
discover every conceivable fault or weakness in a work product. It provides a way to check
the functionality of components, sub-assemblies, assemblies and/or a finished product It is
the process of exercising software with the intent of ensuring that the
Software system meets its requirements and user expectations and does not fail in an
unacceptable manner. There are various types of test. Each test type addresses a specific
testing requirement.
Unit testing
Unit testing involves the design of test cases that validate that the internal program logic
is functioning properly, and that program inputs produce valid outputs. All decision
branches and internal code flow should be validated. It is the testing of individual software
units of the application .it is done after the completion of an individual unit before
integration. This is a structural testing, that relies on knowledge of its construction and is
invasive. Unit tests perform basic tests at component level and test a specific business
process, application, and/or system configuration. Unit tests ensure that each unique path
of a business process performs accurately to the documented specifications and contains
clearly defined inputs and expected results.
SCREENSHOTS
HOME
107
ADMIN
108
USER
109
USER REGISTRATION
110
111
RESULT
Thus the Book Resale Application System was implemented using the specified front end
and back end tools.
112
113
Ex No: 14 TOURS AND TRAVELS MANAGEMENT SYSTEM
Abstract:
The Tours and Travel Management System is a web based application. The main
purpose of “Tours and travels management systemis to provide a convenient way
for a customer to book hotels, flight, train and bus for tour purposes.
The main objective of this project is to develop a system that automates the processes and
activities of a travel agency. In this project, we will make an easier task of searching
places and for booking train, flight or bus.
In the present system, a customer has to approach various agencies to find details of
places and to book tickets. This often requires a lot of time and effort.
We provide approach skills to critically examine how a tourist visits and its ability to
operate in an appropriate way when dealing with the consequences of tourism, locally,
regionally, and nationally including visitor security and ecological influences.
It is tedious for a customer to plan a particular journey and have it executed properly.
The project Tours and Travels Management System’ is developed to replace the
currently existing system, which helps in keeping records of the customer details of
destination as well as payment received.
PROPOSED SYSTEM:
The proposed system is a web based application and maintains a
centralized repository of all related information. The system allows one to easily
access the relevant information and make necessary travel arrangements. Users
can decide about places they want to visit and make bookings online for travel
and accommodation
EXISTING SYSTEM:
In the present system a customer has to approach various agencies to find detailsof
places and to book tickets This often requires a lot of time and effort. A customermay not
get the desired information from these office and often the customer may be misguided
SCOPE OF PROJECT:-
The Website is developed based on real life. It is very helpful in business applications.
Today's extremely exhausting work environment dictates that individuals requires
some joyful holiday. The website will provides a stress-free joyful refreshing holidays
with cost competitive and customized packages according to their requirements
The Website is developed based on real life. It is very helpful in business applications.
Today's extremely exhausting work environment dictates that individuals requires some
joyful holiday. The website will provides a stress-free joyful refreshing holidays with
cost competitive and customized packages according to their requirements
114
HARDWARE REQUIREMNTS:-
RAM: 8GB
SYSTEM TYPE: x64 based processor PROCESSOR: Intel Core 1.50Ghz
SOFTWARE
REQUIREMENTS:
OPERATING SYSTEM:
Windows10
FRONT END: ASP.NET
BACK END: MYSQL
INTRODUCTION
Tour & Travel is an irresistible word when it comes totour and travel packages. Weoffer
tour and travel services including ticket bookings, hotel reservations,rental carservices,
holiday tour packages, domestic tour packages.
Whether you're looking for aweekend getaway to relax and indulge, a special holiday
with friends and family, atrip to your favorite chill out spot or a new adventure, you've
come to the right place.Tour & TravelTravel offers great deals and discounts on flights,
railways, hotels,holiday packages, car rental and travel activities everything you need
to plan, shop
Modules of travel and tour management system:-
User Management:
a. Login.
b. User profile.
c. Update information.
d. Role based rights.
115
Dataflow Diagram:
LEVEL1:
116
LEVEL 2:
DATABASETABLE:-
Fieldname
Data type
Length
Key
Username
Varchar
20
Primary key
Password
Varchar
25
-
Status
Varchar
10
-
User Registration:-
Fieldname
Data type
Length
Key
USERNAME
Varchar2(4000)
NO
-Primary
NAME
Varchar2(4000)
NO
-
ADDRESS
Varchar2(4000)
NO
-
PHONENO
Varchar2(66)
YES
-
PINCODE
Varchar2(66)
YES
-
EMAIL
Varchar2(4000)
YES
-
117
HOTELRESULT:
Fieldname
Data Type
Length
Key
IMAGE
BLOB
YES
-
HOTELNAME
Varchar2(4000)
YES
-
HOTELADDRESS
Varchar2(4000)
YES
-
HOTELTYPE
Varchar2(4000)
YES
-
HOTELPRICE
Varchar2(4000)
YES
-
FACI
Varchar2(4000)
YES
-
TOURBOOK:
Fieldname
Data Type
Length
Key
REQNO
Varchar2(40)
NO
-
NAME
Varchar2(40)
YES
-
ADDRESS
Varchar2(40)
YES
-
PHONENO
Varchar2(40)
YES
-
EMAILID
Varchar2(40)
YES
-
TOURNAME
Varchar2(40)
YES
-
CANTRY
Varchar2(40)
YES
-
TORIST
Varchar2(40)
YES
-
ARRIVEL
Varchar2(40)
YES
-
RETURN
Varchar2(40)
YES
-
HOTELNAME
Varchar2(40)
YES
-
ROOMS
Varchar2(40)
YES
-
ADULTSC
Varchar2(40)
YES
-
CHILDERN
Varchar2(40)
YES
-
DETAIL
Varchar2(40)
YES
-
TOUR-STATUS
Varchar2(4000)
YES
-
HOTEL-
STATUS
Varchar2(4000)
YES
-
ROOMNO
Varchar2(4000)
YES
-
118
CARBOOKING:
Fieldname
Data Type
Length
Key
REQNO
Varchar2(40)
NO
-Primary
NAME
Varchar2(40)
YES
-
ADDRESS
Varchar2(40)
YES
-
PHONENO
Varchar2(40)
YES
-
EMAILID
Varchar2(40)
YES
-
VIHICLE
Varchar2(40)
YES
-
PICUP
Varchar2(40)
YES
-
CANTRY
Varchar2(40)
YES
-
PASSENGER
Varchar2(40)
YES
-
ARRIVAL
Varchar2(40)
YES
-
RETURN
Varchar2(40)
YES
-
CAR
Varchar2(40)
YES
-
ADMIN:-
LOGIN-
119
PLACE LIST:-
120
CONCLUSION:-
The automated Tours and Travels Management System is more fuction because of people
can get their package to the authority
RESULT:-
Thus, the Tours and Travels Management System was implemented using the specified
front and back end tool
121
Ex No: 15 APPLYING DATA MINING IN CYBER CRIME
PROBLEM DEFINITION
Our project is based on the reliability and availability of network services are being
threatened by the growing number of Denial-of-Service (DoS) attacks.
Effective mechanisms for DoS attack detection are demanded.
Investigate and extract second-order statistics from the observed network traffic records.
These second-order statistics extracted by the proposed analysis approach can provide
important correlative information hiding among the features.
By making use of this hidden information, the detection accuracy can be significantly
enhanced.
INTRODUCTION
Cloud computing is a recent technology that aims at providing access to resources instantly
as per the needs of the end users. Cloud enables its customers to make use of the resources
that are widely distributed in the internet to perform computations without installing in
their own PCs and has to pay only for the service they consumed. All the computational
requirements will be taken care of by the cloud service providers and hence all the
complexities involved will be hidden from the user. NIST identifies the five key
characteristics of cloud computing as on- demand self- service, resource pooling, broad
network access, rapid elasticity and measured service.
Cloud offers services in three basic forms namely infrastructure (IaaS),platforms (PaaS)
and Software (SaaS) and is on the stage of evolution to provide everything as a service
(XaaS). As large magnitudes of data are moving onto the cloud, the attackers are keener to
exploit the vulnerabilities associated with cloud and thereby to steal the sensitive data.
Among the various threats tocloud computing, Denial of Service(DoS) attacks can prove to
be the deadliest attack and even the Cloud Security Alliance has identified DoS attack as
one of the nine major threats. In DoS attack, the intruder overloads the target system with
service requests so that it cannot respond to any further requests and hence resources will
be made unavailable to its users. Distributed Denial of Service(DDoS) attack makes use of
several compromised machines called zombies to launch DoS attack on the target machine
and the service is disrupted or delayed.DDoS attacks are getting more frequent these days
and hence proper intrusion detection systems has to be deployed.
This project discusses the 2 various kinds of DDOS attacks possible and the various
countermeasures that need to be followed to avert such attacks.
In computing,a denial-of-service attack (DoS attack) is a cyber-attack where the perpetrator
seeks to make a machine or network resource unavailable to its intended users by
temporarily or indefinitely disrupting services of a host connected to the Internet. Denial of
service is typically accomplished by flooding the targeted machine or resource with
superfluous requests in an attempt to overload systems and prevent some or all legitimate
requests from being fulfilled.
122
In a distributed denial-of-service attack (DDoS attack), the incoming traffic flooding the
victim originates from many different sources.
This effectively makes it impossible to stop the attack simply by blocking a single source.
A DoS or DDoS attack is analogous to a group of people crowding the entry door or gate to
a shop or business, and not letting legitimate parties enter into the shop or business,
disrupting normal operations. Criminal perpetrators of DoS attacks often target sites or
services hosted on highprofile web servers such as banks or credit card payment gateways.
Revenge, blackmail and activism can motivate these attacks.
SYSTEM REQUIREMENTS
Below are the tools, languages and software that were used to develop a Book Resale
Application System:
HARDWARE REQUIREMENTS
Processor
:
Intel Core 2
Speed
:
1.1 GHz
Hard Disk
:
250 GB.
Monitor
:
SVGA
Mouse
:
Optical
Ram
:
1GB
SOFTWARE REQUIREMENTS
Operating
System
:
Windows95/98/2000/XP/7.
Operating
System
Application
Server
:
Tomcat6.0/7/8.X.
Application
Server
Front End
&CSS
:
Java,HTML
Front End
&CSS
Scripts
:
JavaScript.
Scripts
Server side
Script
:
Java Server Pages.
Server side
Script
IDE
:
Eclipse/ Net beans
IDE
Back End
:
MYSQL 5.0/ Heidi SQL 8.1
Back End
123
DATA FLOW DIAGRAM
TESTING
SYSTEM TESTING
The purpose of testing is to discover errors. Testing is the process of trying to discover
every conceivable fault or weakness in a work product. It provides a way to check the
functionality of components, sub assemblies, assemblies and/or a finished product ,it is the
process of exercising software with the intent of ensuring that the software system meets
its requirements and user expectations and does not fail in an unacceptable manner. There
are various types of test. Each test type addresses a specific testing requirement.
UNIT TESTING
Unit testing involves the design of test cases that validate that the internal program logic is
functioning properly, and that program inputs produce valid outputs. All decision branches
and internal code flow should be validated. It is the testing of individual software units of
the application .It is done after the completion of an individual unit before integration. This
is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests
perform basic tests at component level and test a specific business process, application,
and/or system configuration. Unit tests ensure that each unique path of a business process
performs accurately to the documented specifications and contains clearly defined inputs
and expected results.
124
SCREENSHOTS
HOME
ADMIN
125
USER
USER REGISTRATION
RESULT
Thus, the Book Resale Application System was implemented using the specified
front end andback end tools.